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Mail Stop AF 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

SECOND PRE-APPEAL BRIEF REQUEST FOR REVIEW 

The new office action received in response to the first pre-appeal brief withdrew the 
rejection for lack of written description support and the obviousness rejection based on Mitchell, 
Das, Fieschi, and Shew. However, the Examiner makes a new obviousness rejection of claims 1, 
2, 4-10, 12, and 15-20 based on Mitchell and newly-applied Suzuki (USP 6,507,873) and 
secondary rejections adding Das and Ramsayer are used in combination with Mitchell and 
Suzuki to reject dependent claims 13, 14 and 3, 1 1, respectively. There are clear errors in these 
rejections. 

Mitchell describes discovering and registering middleboxes in response to a call set-up 
message. For the middlebox "binding" referred to in [0062], the call servers 18 request the 
middlebox to set up a voice packet path from terminal A, and in response, the middlebox replies 
with a public address and port to which packets from terminal B to terminal A should be sent. 
Unlike the claims which relate to the registration and control of mobile user data packet flows for 
purposes such as QoS differentiation or transcoding, Suzuki deals with something entirely 
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different — address assignment. See, e.g., Suzuki's title "Network address assigning system," 
abstract: "A network address assigning system. . .," and summary and claims: "A network 
address assigning system. ..." 

Clear Error #1: Mitchell and Suzuki Lack the Registration and Control of Mobile User 
Data Packet Flows . 

Step a of claim 1 recites "controlling individual mobile user data packet flows forwarded 
on the IP-based user plane from a common, IP -based control plane provided with one or more 
midcom agents, where the common, IP-based control plane is separate from the IP-based user 
plane," steps b and c relate to registering "each mobile user data packet flow," and step d recites 
"the midcom agent signalling control orders to the registered middleboxes, said orders pertaining 
to the handling of the mobile user data packet flows at respective middleboxes in the IP-based 
user plane." Nowhere does the office action explain where either Mitchell or Suzuki teaches the 
registration and control of mobile user data packet flows. 

The office action simply identifies "each flow (i.e. call set-up message)" on page 3. But 
a call set-up message is a control message and not an "individual mobile user data packet flow[] 
forwarded on an IP -based user plane, where each mobile user data packet flow is separate and 
different from session set up messages sent with IP layer control signaling and/or session layer 
control signaling," as recited in claim 1. Mitchell's call set-up message from terminal A to 
middlebox 1 and from middlebox 1 to the call server 18 (midcom agent) cannot be mapped to the 
claimed mobile user data packet flow. 

The data flow/bearer B in Mitchell does not register its presence in each middle box as 
recited in step b of claim 1 : "each mobile user data packet flow registering its presence in each 
middlebox it encounters on its way from its source to its destination in the IP based user plane." 
In fact, the bearer connection B, which Applicants believe corresponds to the user data flow 
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between the middleboxes 1 and 2 and users A and B in Figure 6, is not described in much detail 
by Mitchell outside of paragraph [0046]. Ultimately, Mitchell does not disclose how middlebox 
registration handles mobile user data packet flows. 

Nor does the Examiner identify what in Suzuki teaches "mobile flows" - let alone 
individual mobile user data packet flows. The office action simply identifies "network 
addresses" and "address information" which plainly is not individual mobile user data packet 
flows. So even if these two references could be combined, which they cannot be, they fail to 
teach the registration and control of mobile user data packet flows. 

Clear Error #2: Mitchell and Suzuki Lack the Claimed Middlebox and Midcom Agent 
Functionality . 

Page 4 of the new office action admits that Mitchell lacks a teaching of multiple elements 

recited in claim 1 including for example: (1) middlebox registration at a midcom agent (mapped 

onto call servers/proxies 18 in Figure 6) or at middleboxes (mapped onto middleboxes 10, 11) 

(see step b of claim 1), (2) "the common, IP-based control plane is separate from the IP-based 

user plane," (3) "each mobile user data packet flow is separate and different from session set up 

messages sent with IP layer control signaling and/or session layer control signaling." For the 

admitted missing features, the Examiner turns to Suzuki's abstract, figure 2, and col. 4, lines 17- 

24 quoted here for convenience: 

FIG. 4 shows the first method of the address deciding process. 
Referring to FIG. 4, an address server 1 notifies routing nodes 2 to 
5 connected to a main network 16 of addresses of the routing nodes 
2 to 5. When a network address of a routing node is changed, the 
address server 1 notifies other routing nodes of relevant address 
change information. 

First, the Examiner never clearly identifies what in Suzuki is the middlebox, midcom 
agent, control plane, or user plane. It seems like the Examiner may be mapping Suzuki's routing 
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nodes 2-5 to middleboxes and address server 1 to a midcom agent. A person of ordinary skill 
would not make such a mapping. As can be gleaned from Mitchell, a middlebox processes user 
data packets in addition to traditional best-effort store and forwarding. Examples of such 
middlebox processing include QoS differentiation or transcoding. This processing is controlled 
by a midcom agent. Suzuki's invention is directed to handling address management for 
basic connectivity and not user data packets. Thus, it is not meaningful to map the nodes 
described in Suzuki to middleboxes or midcom agents. 

It is also important to remember that claim 1 is not simply reciting any node registering 
with another management node. Rather, step c in claim 1 specifically recites: "in response to 
step b [user data flow registration in each middlebox], each middlebox in the IP based user plane 
registering itself and the identities of mobile user data packet flows it handles in the IP based 
user plane at a midcom agent in the common, IP-based control plane using an extended midcom 
signalling protocol." Suzuki does not teach the claimed middlebox or midcom agent. 

Ultimately, Mitchell and Suzuki do not disclose or suggest registering mobile user data 
flows that move between different middleboxes so that movement of a mobile terminal or a 
moving network can be accommodated. The Examiner never explains how fixed router node 
network addresses or address changes in Suzuki is the same as mobile user data flows. In 
addition, there is no teaching in Mitchell or Suzuki of registering the mobile user data flow 
identities at a midcom agent together with the identity of the middlebox that the flow traverses 
allows the flow to be bound to a specific flow control process in the midcom agent even though 
the flow may move between different middleboxes during a call. 

Moreover, claim 1 is not reciting an IP-based control plane separate from an IP-based 
user plane in a vacuum. The Suzuki reference is a general router addressing reference, and the 
Examiner makes no attempt to identify where Suzuki teaches middleboxes, midcom agents, and 
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the interactions between them and mobile user data packet flows. The piece-meal approach to 
the rejection is evident and improper. The pre-appeal panel is reminded that each claim and each 
reference must be considered as a whole. 

Clear Error #3: The Combination Is Improper . The Examiner tries to justify the combining 
Suzuki with Mitchell because it "would benefit the system to reliably route packets." But the 
Examiner never explains why or how Suzuki's network addressing scheme would benefit 
Mitchell. The object in col. 2, lines 43-46 used by the Examiner to support this allegation deals 
with a moving routing node and managing address "in a multi-home format." But Mitchell is not 
using moving routers, so this object is irrelevant. 

The mere fact that references might somehow be combined or modified does not render 
the resultant combination obvious unless the results would have been predictable to one of 
ordinary skill in the art. See, e.g., KSR International Co. v. Tele/lex Inc. , 82 USPQ2d 1 3 85, 1 396 
(2007); MPEP §2143.01 .III. No predictability is demonstrated by the Examiner. Indeed, the two 
references are directed to very different problems and technology areas. 

The deficiencies with Das were addressed in the last pre-appeal. Ramsayer does no more 
to overcome the clear errors set forth above. These rejections, which are no more relevant than 
the ones withdrawn in response to the first pre-appeal, should also be withdrawn. The 
application should be allowed. 



Respectfully submitted, 



NIXON & VANDERHYE P.C. 



By: 




John R. Lastova 
Reg. No. 33,149 



Nixon & Vanderhye PC 
901 North Glebe Road, 1 1th Floor 
Arlington, VA 22203-1808 
Telephone: (703) 816-4000 
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